home *** CD-ROM | disk | FTP | other *** search
- Path: news.th-darmstadt.de!news!enno
- From: enno@inferenzsysteme.informatik.th-darmstadt.de (Enno Sandner)
- Newsgroups: comp.lang.c++
- Subject: Re: locking
- Date: 13 Jan 1996 16:25:30 GMT
- Organization: Fachbereich Informatik, TH Darmstadt
- Distribution: world
- Message-ID: <ENNO.96Jan13172530@kitz.inferenzsysteme.informatik.th-darmstadt.de>
- References: <4d0j6r$1ri@daphne.ecmwf.int>
- <30F3E9C3.15FB7483@intellektik.informatik.th-darmstadt.de>
- <4d8eu8$phs@gidora.kralizec.net.au>
- NNTP-Posting-Host: kitz.intellektik.informatik.th-darmstadt.de
- In-reply-to: jon@zeta.org.au's message of 13 Jan 1996 14:17:44 GMT
-
- In article <4d8eu8$phs@gidora.kralizec.net.au> jon@zeta.org.au writes:
-
- In <30F3E9C3.15FB7483@intellektik.informatik.th-darmstadt.de>, Enno Sandner <enno@intellektik.informatik.th-darmstadt.de> writes:
- >Baudouin Raoult wrote:
- >
- >I would say the temporary object should be destroyed directly after
- >the invocation of 'bar'.
-
- It is up to the compiler to decide when it is destroyed. According to the (ARM 12.2)
- it must be destroyed by the end of the scope which created it, but it
- is implementation dependent as to when it actually is destroyed.
- Not knowing exactly when the temporary is destroyed means that
- it is impossible to make strong assertions about the state of the
- object referred to by fooH after fooH->bar() returns.
-
- Refer to my articles in comp.lang.c++.moderated on this subject for my
- other comments about the (non-)safety of this locking technique.
-
- According to the DWP (12.2) the temporary gets destroyed (in this situation)
- at the end of the 'full-expression'. Thus it gets destructed directly after
- the invocation of 'bar'.
- Anyway as Wil Evers already pointed out it is currently a bad idea to rely
- on that behavior.
-
- Enno
-
-
-
-